FIG. 1 depicts business system 100 in the prior art. Business system 100 implements one or more business processes, such as a purchasing process. System 100 comprises business process engine 101, human resources database server 102, purchasing system 103, inventory system 104, terminal 105, and enterprise telecommunications system 106, interconnected as shown.
Business process engine 101 is a data-processing system that executes one or more workflow scripts that are written in the business process execution language, or “BPEL.” BPEL represents information such as when to wait for messages, when to send messages, when to compensate for a failed transaction as part of an “exception condition,” and so forth. This information is programmed by a business consultant through programming console 105 at installation time when the consultant sets up the related business application.
During run-time of a business application that comprises, for example, a purchasing process, engine 101 accepts purchasing transactions from purchasing system 103. When a purchaser fills out a purchase order for an item via purchasing system 103, engine 101 runs a workflow that is associated with the purchasing process. The workflow, among other things, determines whether the item is in stock or not. If the item is in stock, the purchasing process proceeds normally. If the item is not in stock, however, the workflow triggers an exception condition that needs to be corrected. The exception condition might result in inventory system 104 being contacted to determine how to correct the out-of-stock problem; system 104, in turn, identifies the various business roles that need to be consulted, such as inventory management and account management, and provides those roles back to engine 101. Engine 101 then determines the people to contact by consulting with human resources database server 102 and subsequently triggers enterprise telecommunications system 106 to transmit email to the affected parties, such as the person in charge of re-ordering the out-of-stock item, the account executive of the customer who attempted to order the item, and so forth. Alternatively, those affected parties might be contacted by telephone through the use of one or more telephony functions.
The integration of business processes with telephony functions, however, has often been anything but straightforward. For example, one of the key problems with any telephony-based application is the cost of feature development. As the time to develop a feature increases, so does the cost of the feature. Furthermore, the more features that are to be offered in a system, the more protocols the associated application must understand. The cost can grow exponentially as a function of the number of features or protocols present.
Additionally, once the base telephony infrastructure is in place and telephone calls can be made, the customer will often want to add applications to the platform. Often, these applications, such as the purchasing process described earlier, require customized behavior in the system, in which the customization might have to change from time to time. This can be difficult to achieve given the breadth of features, communication protocols, and application program interfaces that are available in modern telephony systems.
What is needed is a technique for interfacing business processes with telephony functions, without some of the disadvantages in the prior art.